COMMENT ⊗   VALID 00005 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	∂10-Jan-78  0053	FTP:LEFAIVRE at RUTGERS-10 	New RUTGERS/UCI LISP Taking Shape    
C00009 00003	∂03-Mar-78  1323	FTP:LEFAIVRE at RUTGERS-10 	Notice of new LISP system which went to all Rutgers LISPers   
C00024 00004	∂10-Apr-78  1315	LEFAIVRE at RUTGERS-10 	NEW RUTGERS/UCI LISP SYSTEM RELEASED
C00030 00005	∂03-May-78  0713	LEFAIVRE at RUTGERS-10 	LISP Documentation   
C00044 ENDMK
C⊗;
∂10-Jan-78  0053	FTP:LEFAIVRE at RUTGERS-10 	New RUTGERS/UCI LISP Taking Shape    
Date:  9 Jan 1978 (Monday) 2230-EST
From: LEFAIVRE at RUTGERS-10
Subject: New RUTGERS/UCI LISP Taking Shape
To: @LISP.ARP[3442,46] at RUTGERS-10:

Dear LISPer:

This letter is being sent to all known users (and potential users) of
RUCI LISP (RUTGERS/UCI LISP),  which is now in use at around 25 sites
and continues to spread.  I would like to thank those of you who have
notified  me of bugs and made suggestions for improvements.  A number
of bugs have been corrected over the past year -  I  can't  guarantee
that there are none left, but they are getting more and more obscure.
A number of improvements have also been made - I can't even begin  to
describe them all here, but a few are mentioned below.

The  real  reason  for this note is to inform you that in addition to
improvements to existing modules and  a  host  of  new  functions,  a
couple  of  changes  have  been  made  which  affect  existing files.
This will cause  some  temporary  inconvenience  (although a  MIC/SOS
conversion file will be provided), but I feel the final product  will
be worth it.  The changes include:

- The system is now called LISP, with the compiler called LISPC.  The
initialization  file  is  now  LISP.INI,  and  you  can  also  have a
LISPC.INI, PLNR.INI, CNVR.INI, or FUZZY.INI.

- The QUOTE macro character has finally been changed from @ to  '  to
make  us compatible with the rest of the LISP world.  @ will continue
to be recognized (unless it is MODCHRed), but the prettyprinter  will
now output '.

-  The  comment  functions  have  been  changed to ; and ;; (* is now
equivalent to *TIMES).  (; ...) comments are printed off to the right
of  the  listing,  and  (;;  ...) comments are printed at the current
indentation level.

- The "ignored CR/LF" character used  to  break  atoms  over  a  line
boundary is now ~ (tilde - ASCII 176).  ↑Y, like ↑Z before it, caused
problems on certain terminals - they will continue to  be  recognized
on  input  so  that  existing  files  can  be read, but ~ will now be
output.  Because of the strange handling of  ASCII  176  in  monitors
prior to 6.03, I am hoping that no one has files containing tildes.

-  The  default  integer  base  is  now  10.,  with  *NOPOINT=T  (but
*NOPOINTDSK remains NIL so that files can be dumped and read back  in
correctly).

-  The  old  CURRCOL is now called CHRPOS - CHRPOS and CHRCT now read
the actual carriage position of the TTY, so it doesn't matter whether
the  last  input  line was terminated with CR or ALTMODE (this is now
used to provide a nicer top-level).

- Lower-case letters in atomic symbols will now be  raised  to  upper
case  (unless  slashified  or  in a string) if *RAISE=T (*RAISEDSK is
used for file input).

- There  is  a  new  MACROEXPANSION  feature  which  can  be  set  to
automatically  save  a  macro  expansion so that it is only done once
(its operation is transparant to the user).  Makes a  big  difference
for complex macros.

- Some new code from Texas supporting SFDs and random access input is
now being tested.

-  There is a new SORT/MERGE package from CMU, a string concatenation
function, a way to control the file protection used  for  new  files,
some new macros, and a lot of other generally useful stuff.

I  hope  to  have  the  new  system  completely  tested and ready for
distribution in February, and have thus been sitting on the  tapes  I
now  have.  Others are welcome to send a tape, or if you prefer, drop
me a note and I'll send you the revised Rutgers documentation and you
can  see  for  yourself  what's there (although you won't see the bug
fixes and the many undocumented internal improvements). There is some
hope  that  a  comprehensive manual will be written this year, but no
one should hold their breath waiting for it.

As usual, questions or comments are welcome.

					- Prof. Rick LeFaivre
					  Computer Science Dept.
					  Hill Center, Busch Campus
					  Rutgers University
					  New Brunswick, NJ  08903


∂03-Mar-78  1323	FTP:LEFAIVRE at RUTGERS-10 	Notice of new LISP system which went to all Rutgers LISPers   
Date:  3 Mar 1978 (Friday) 1622-EST
From: LEFAIVRE at RUTGERS-10
Subject: Notice of new LISP system which went to all Rutgers LISPers
To:   CRIS.PERDUE at CMU-10A, TYSON at UTEXAS-, DIFFIE at SU-AI

To our long-suffering LISP users:

Well, the new version of LISP finally appears ready to go.  It currently
resides in LSP:LISP, and I would like to ask all of you to give it a
workout before I move it over to SYS:.  You may run it via .R LSP:LISP,
with the new compiler being accessed via .R LSP:LISPC.  Please try out any
previous bug-producing code - many minor problems have been fixed in
this release, but if there are any left which I missed, or (heaven forbid)
any new bugs which have been introduced, please let me know as soon as
possible.

Most of the mofifications involve bug fixes and extensions, but there
have been a couple of actual changes as well which you must be
aware of.  First, I finally decided against changing the "ignored cr/lf"
character from ↑Y to ~, so the tilde character is still available for
general use.  The terminal problem has been solved by not ouputting ↑Y's
to terminals - they are now used for breaking atoms over line boundaries
in files only.

The major change involves the handling of comments:  the new comment functions
are ; (replacing *, which is now equivalent to *TIMES), and ;; (replacing
** and ***).  ; comments print starting in column 40, and ;; comments
print at the current level of indentation.  Although comments may still
be input as list structures (i.e., (; This is a comment)), the preferred
mode, and the mode used by the prettyprinter, is to use braces:
{; This is a comment.}.  "{" is defined as a printmacro which reads
everything from the comment function to the "}" and stores it as a
string, saving considerable space and allowing special characters such
as period to appear in comments.  The prettyprinter knows how to print
such packed comments correctly.  They are a pain to edit, however, so
the new edit command UNPACK has been added to unpack a comment from its
string representation back to a list form.  There is no need to convert
it back again, as this will be done by the prettyprinter so that it will be
read as a string the next time the code is loaded.

Most of the other actual changes involve functions which are no longer with
us:  PP* (both function and edit command) and PPL* have been changed to
PP; and PPL; (there is also a P; edit command); CURRCOL is now called
CHRPOS; *INSERT, *MERGE, and *SORT are gone (INSERT, MERGE, and SORT
now accept missing arguments); LEXORDERCAR is gone (LEXORDER automatically
moves to the left most atom of each argument); the RAISE function has
been replaced by a *RAISE flag - if *RAISE=T, all chars read by READ
will be raised to upper case except those in strings and slashified chars;
and the QUOTE macro character has been changed to ' (although @ will still
be recognized on input).  Finally, the LISP initialization file is now
called LISP.INI instead of INIT.LSP.  The compiler uses a separate init
file, LISPC.INI.

Even though these changes are not substantial, I realize the inconvenience
of having to change things over by hand.  I have therefore put together a
conversion package for you to use.  To convert any existing file, simply
start lisp going, do a (DSKIN LSP: (CONVRT.LSP)), DSKIN your code as usual,
and then do one or more DSKOUTs to recreate your LSP files.  All of the
above changes (except the *RAISE change) will be made for you automatically.

In addition to these changes, there have been a number of extensions
made to the system.  These will be described in a new version of ILISP.MAN
in the near future, but until then I'll whet your appetites with a brief
overview of some of the major additions:

- There is now a new string representation which removes the old confusion
  between strings and litatoms.  Strings now take up less space than
  litatoms, they don't have property lists, and they evaluate to themselves
  like numbers.  LITATOM, STRINGP, and NUMBERP now define three disjoint
  classes of ATOMs.

- DSKOUT is now somewhat more useful as a file-handling function:
  (DSKOUT (file.ext)) will see if the atom fileFNS is bound - if so,
  it will be passed on to PPL.  If not, fileFNS will be bound to the
  value of (SORT (APPEND ALLVALS ALLFNS)) and passed to PPL.  Thus
  (DSKOUT (file.LSP)) is a quick way to save everything you've typed
  in during this session.

- User-defined ersatz devices are now supported.  You may associate a
  ppn with a device name using a DEVPPN property:

	(DEFPROP RICK: (3442Q 46Q) DEVPPN)

  RICK: may now be used anyplace an actual ppn can be used, including
  in DSKIN/OUT and DIRF.

- SFD's are now supported, in the form (proj# prog# sfd1 sfd2 ...).

- Random access input is now supported:  (UGETI) and (UGETO) return
  the byte position of the next char to be input or output on the
  current channel (except for the TTY).  (USETI byte) sets the input
  pointer to read from the current input channel starting at that byte.
  (The random access and sfd code came to us from the Univ. of Texas).

- FILPRO now gives the desired file protection for files written by
  LISP (NIL implies use your default protection).

- Macro expansions are now automatically saved so they are only
  expanded once.

- Missing args to SUBRs and EXPRs are now set to NIL by the system.

- PP only unbreaks functions when they have been broken-into, i.e.,
  the code has been modified by the break package.

- TRACE now accepts a conditional trace condition, and you can specify
  whether the trace is to go to the terminal or the current output
  channel.

- There are several new macros, including PUSH, POP, INCR, DECR, F:L,
  and a fancy SAIL-like DO macro.

- %PRINFNTOP is bound to the top-level print function.  It is initially
  PRIN1, but may be changed by the user.

- There are a number of more useful names for old functions.  They include
  + (*PLUS), - (*DIF), * (*TIMES), // (*QUO), +I (ADD1), -I (SUB1),
  = (EQUAL), LT (*LESS), GT (*GREAT), LE, GE (new fns), PRIN (PRIN1),
  MAPL (MAPLIST), MAPCL (MAPCAR), and CONSCOUNT (SPEAK).

- File backups are now better maintained.  FILBAK is set to Q, and is
  inserted into the extension a la SOS.  A secondary backup is now
  maintained, so that unless changed by the user, LISP keeps three
  copies of a file:  FOO.LSP (or whatever) is the most recent version,
  FOO.QSP is the next most recent, and FOO.QBK is the original version.
  This is a compromise between just keeping the two most recent versions
  (as was done before) and keeping multiple versions.  One always can be
  assured that FOO.QBK is the original version of FOO, dating back to
  the last time a .DELETE FOO.Q?? was done.  The secondary backup is
  under the control of the variable FILBAKBAK - if NIL, no second backup
  is kept, else it gives the extension.

- EVERY and SOME now take multiple args like the other map functions.

- FIX is a new break command which combines EDIT and EX.  EX takes an
  optional location spec.

- SORT and UNPACK (mentioned above) are new EDIT commands.  MBD, XTR,
  and : now work on top-level list structures.

Well, I could go on, but you get the idea.  Those of you who want
information about the new system should get in touch with me.  I
won't promise when the new manual will be ready, since there are a
number of changes.  Again, let me know if any bugs turn up.

∂05-Mar-78  0255	WD  	NEW LISP SYSTEM
To:   LEFAIVRE@RUTGERS-10
	I got your message.  Now I need to know what files I should
copy.  I will start by just trying to FTP them, since you
think that will now work, and get back to you if it doesn't.
				Thanks,
					Whit

∂05-Mar-78  1256	FTP:LEFAIVRE at RUTGERS-10 	NEW LISP    
Date:  5 Mar 1978 (Sunday) 1558-EST
From: LEFAIVRE at RUTGERS-10
Subject: NEW LISP
To:   WD at SU-AI

Whit-

LSP:LISP.EXE and LSP:LISPC.EXE are the newest LISP and LISP compiler sav
files, but they are modified to run out of LSP:[11,10].  To build new
versions to run out of SYS: or some place else, you can use LSP:LISP.MIC
and LSP:LISPC.MIC to build the sav files.  Probably the easiest way to
insure getting everything you need is to copy everything of the form
LSP:LISP.*, LSP:LISPC.*, LSP:SYMMAK.*, and LSP:LOADER.*

∂05-Mar-78  1304	FTP:LEFAIVRE at RUTGERS-10 	UPDATE 
Date:  5 Mar 1978 (Sunday) 1606-EST
From: LEFAIVRE at RUTGERS-10
Subject: UPDATE
To:   WD at SU-AI

Sorry, you also need LSP:LAP, LSP:BREAK.LAP, LSP:ERRORX.LAP, LSP:PP.LAP,
and LSP:EDIT.LAP.

So far no bugs have turned up.  I'm keeping my fingers crossed.  By the way,
you will notice that the compiler now allocates free acs from 5 down instead
of from 1 up.  Doesn't seem to make a great deal of difference, but there are
several instances when things can stay in 5 and not have to be pushed.  The
compiler was also fixed to compile the map fns like they are interpreted, i.e.,
the CDRs are taken and saved before the function is called, letting one map
down a list and do rplacds if desired.

∂10-Apr-78  1315	LEFAIVRE at RUTGERS-10 	NEW RUTGERS/UCI LISP SYSTEM RELEASED
Date: 10 Apr 1978 (Monday) 1521-EST
From: LEFAIVRE at RUTGERS-10
Subject: NEW RUTGERS/UCI LISP SYSTEM RELEASED
To: @LISP.NET[3442,46] at RUTGERS-10:

Greetings!

The new version of RUTGERS/UCI LISP is (finally) finished.  I really
want to apologize for taking so long - especially to those of you who
have sent me tapes.  It was a case of thinking I was "just around the
corner" for several months, while bugs kept cropping up and new features
were being added.  Anyway, things are now stabilized - the system has
been extensively debugged here at Rutgers, and everything looks fine.
In the process of testing out some new code in the compiler (having to
do with compiling MAPs in a better way), I discovered a deeply-embedded
bug which took a good deal of time to excise.  It had evidently been
around for years, and was particularly unpleasant because it didn't
cause a compiler error, just slighltly screwy code.  Anyway, it has
been fixed and the compiler seems to be in good shape.

If I already have a tape of yours, I will mail it out tomorrow.  If I
don't have a tape and you want to get the new system, send me one.  I
don't know how feasible it is to send large files over the net, but if
you want to try, I understand that Rutgers doesn't require you to log
in to retrieve files.  Everything is in LSP: [11,10] - the system is
now called LISP, and at a minimum you need LISP.EXE, LISPC.EXE, LISP.LOD,
and LISP.SYM.  The Rutgers portion of the documentation (which has been
updated extensively) is in LSP:RUTLSP.MAN.  You might start by retrieving
this document and checking out all of the new features.  In addition to
the new stuff, there have been a number of (mostly minor) bug fixes, and
several outright changes:

- The comment atoms have been changed from *, **, and *** to ; (print to
  the right) and ;; (print at current indentation level).

- *SORT, *MERGE, and *INSERT are gone (SORT, MERGE, and INSERT now take
  optional arguments).

- LEXORDERCAR is gone (LEXORDER takes CARs until atoms are reached).

- CURRCOL is now called CHRPOS.  Note that CHRPOS and CHRCT now work
  properly even when the last READ was terminated with an ESCAPE.

- All of the MAP functions now take their CDRs before applying the function
  (the compiler used to do it one way, the interpreter the other), so one
  can map over a list and do RPLACDs if desired.

- The QUOTE macro character is now ' (although @ will also be recognized).

- The initialization files are LISP.INI, LISPC.INI, etc.

- The default number base is decimal, with *NOPOINT=T (but *NOPOINTDSK
  remains NIL).

- The "ignore rest of line char" remains ↑Y, but it is only used for
  files (i.e., it is not sent to terminals).

A conversion file, LSP:CONVRT.LSP, is available for converting existing
files with comments, CURRCOLs, etc., to the new conventions, so it
should be quite painless.  Because of some changes in the compiler,
however, existing LAP files should be recreated (to sweeten this prospect
for you, the new code should take up slightly less space than the old
code because of some new optimizations in the compiler).

As usual, questions or comments to LEFAIVRE@RUTGERS-10.

∂03-May-78  0713	LEFAIVRE at RUTGERS-10 	LISP Documentation   
Date:  3 May 1978 (Wednesday) 1015-EST
From: LEFAIVRE at RUTGERS-10
Subject: LISP Documentation
To:   MEEHAN at MIT-AI
cc:   CRIS.PERDUE at CMU-10A, DIFFIE at SU-AI, TYSON at UTEXAS-

Jim-

How is your new LISP document coming along?  It is quite obvious that a
comprehensive manual is needed, but finding the time to do this type of
work is always a problem.  I feel that if anything more than a trivial
amount of effort is expended, it should be towards writing a completely
new manual, ideally with a smaller LISP primer as a companion.  The only
old documentation I would include directly is the description of the editor,
and even there I have found a number of minor errors over the years.  I
would like to propose the format of my RUTLSP.MAN as a reasonable stylistic
guide, but of course that is subject to individual tastes.

Both Whit and Cris have previously volunteered to do some work on such a manual,
and perhaps they will get in touch with you if you would like to coordinate its
development.  It will be rather difficult for more than one person to work on
it, especially since you have no file access to the net, but hopefully some-
thing can be worked out.  The reason that I am not volunteering to actively
develop the documentation here is that I will be leaving Rutgers as of June 1
to join the Computer Research Group at Tektronix Laboratories in Portland,
Oregon.  I finally decided that the academic grind just wasn't worth it,
especially at lower pay, and got kind of fed up living in New Jersey.  Anyway,
I will no longer have direct access to the net (I may keep a mailbox here at
Rutgers just as you do at MIT).  I will have a 10 at Tek, and hope to continue
supporting LISP - if you can think of some reasonable way to segment the manual
I would still like to produce a joint document with you.

I hope you got the new system - I am quite pleased with it now.  Note that
because of user reaction against losing "~" as a semi-usable character, I
decided against changing the ignored crlf character from ↑Y - I did take
Cris Perdue's advice, however, and change things so it is not sent to a
terminal.  As seems to always happen the day after I mail a tape out, a minor
problem appeared in the system after your tape was mailed.  It seems that
the new MACROEXPANSION feature was not quite as transparent to the user as
I had hoped.  Specifically, MACROEXPANSIONs occasionally appeared in errorx
backtraces (nothing serious, except it tends to confuse the unsophisticated
user), and reappeared in a function being edited if an Eval of the function
was made while in the editor.  I have fixed these problems (as of April 24)
by putting a binding for MACROEXPANSION in //BREAK1 and EDITL - in other
words, macro expansions won't be saved while in the break package or the
editor.  I also changed the (SETQ %%CMDL --) in the COND at UNMAC in //BREAK1
to the following, which insures that saved macro expansions inside of an
expression on the stack will be undone:

	(AND [SETQ %%CMDL (NEXTEV (SUB1 %%CMDL))]
	     [NEQ (STKNAME %%CMDL) '//BREAK1])

Cris uncovered another bug in the system which apparently goes back to
the time eval blips were added when converting from LISP 1.6 to UCI LISP.
It has to do with *FUNCTION (which is why it was never noticed!).  *FUNCTION
simply returns a stack pointer to the current top of the SPDL, including any
eval blips which were added for the *FUNCTION expression and anything it is
embedded in.  This causes problems, as these eval blips usually go away
before the funarg is applied, and a binding might occur in the stack space
which used to be occupied by the old eval blips.  Anyway, it can be fixed
(and is fixed in the April 24 version) by replacing the ADD A,SPNM at
FUNCT+2 with the following code to move past any eval blips:

	HRRZ T,SC2
FUNCT1:	CAMG A,T
	JRST FUNCT2
	HLL A,(A)
	TLZE A,-1
	JRST FUNCT2
	SOS A
	SOJA A,FUNCT1
FUNCT2:	ADD A,SPNM

Let me know how your documentation work is coming, and what you feel should
be done by others.  One thing we would have to do if we segment it is to
have a common RUNOFF, and yours sounds better than mine if it supports a
table of contents.  Would you like to send me a copy (hopefully with some
reasonable documentation - ours is virtually undocumented).

∂31-May-78  1131	LEFAIVRE at RUTGERS-10 	New LISP Compiler    
Date: 31 May 1978 (Wednesday) 1427-EDT
From: LEFAIVRE at RUTGERS-10
Subject: New LISP Compiler
To:   TYSON at UTEXAS-, DIFFIE at SU-AI, CRIS.PERDUE at CMU-10A

Mabry Tyson at the University of Texas discovered a bug in the compiler
which has evidently been around since LISP 1.6 days (at least it is present
in the old 1.6 compiler we have here).  It involves an optimization which
tries to turn GOs inside of CONDs to conditional jumps (this shouldn't
be done in certain situations, having to do with the state of the stack
in the COND vis-a-vis the outer PROG).  Anyway, LSP:LISPC.LSP/LAP[11,10]
at Rutgers contains a corrected version.  I also updated LSP:CTEST to
include a check for this bug (RB13).

As more novice type LISPers try to use the compiler, I have gotten
complaints that some of the warning messages are not too clear.  For
example, LOCAL AND SPECIAL was a particularly misunderstood message.
I have thus revised some of the messages, and included a section in my
RUTLSP.MAN explaining them.  The following is extracted from LSP:RUTLSP.MAN:

Compiler Warning Messages

     Following is an updated list of warning messages  which  the
compiler  may  output during compilation, and a brief explanation
of each:

<fn> <type> PREVIOUSLY USED AS SUBR

        <fn> has just been defined as a function of  type  <type>
        (FSUBR,   LSUBR,   or   MACRO).   Unfortunately,  it  was
        referenced  before  it  was  defined,  and  the  compiler
        compiled  the  reference  as  a  SUBR  call.   Either the
        definition  should  be  moved   before   any   references
        (necessary   for  MACROs),  or  the  function  should  be
        declared via *FSUBR or *LSUBR.

<fn> <type> PREVIOUSLY USED AS FUNCTIONAL VARIABLE

        <fn> is used as both a function name and as the name of a
        variable.   It was referenced as a function before it was
        defined, and the compiler (probably incorrectly)  assumed
        it  was  a  functional  variable.   It  should  either be
        declared or defined before it is called.

<fn> PREVIOUSLY USED WITH INCORRECT NUMBER OF ARGUMENTS

        A reference was made to <fn> with too  many  or  too  few
        arguments before the function was defined.  If the intent
        was to have missing arguments  set  to  NIL,  either  the
        function  should be defined before it is referenced, or a
        (*SUBR (<fn> <n>)) declaration should be made.

<fn> EXTRA ARGUMENTS PRESENT

        Self-explanatory.  No harm done, but probably an error.

(<var1> . . . ) UNDECLARED SPECIAL VARIABLES IN <fn>

        The indicated variables appeared free in <fn>.  They will
        be  declared  SPECIAL by the compiler, with no harm done.
        To remove the message from future compilations, a SPECIAL
        declaration should be made.

<var> UNUSED PROG VARIABLE (ASSUMED SPECIAL) IN <fn>

        An unused PROG  variable  is  assumed  to  be  a  special
        variable to be used by some lower-level function.  Again,
        a declaration will be made by the compiler, with no  harm
        done.

<var> SPECIAL VARIABLE PREVIOUSLY USED AS LOCAL

        A newly  declared  or  discovered  special  variable  was
        previously  referenced  as a local variable.  Unless this
        was intentional, a special declaration should be made for
        the variable.

<var> REPEATED VARIABLE IN <fn>

        <var> was bound more than once in <fn>.

<tag> UNDEFINED TAG IN <fn>

        Self-explanatory.

<tag> MULTIPLY DEFINED TAG IN <fn>

        Self-explanatory.

∂31-May-78  1319	DON  
To:   RWG
CC:   WD    
 ∂31-May-78  0613	RWG  
To:   DON, WD
rem has asked me to think about "how overlays should really work",
with the possibility that he might modify pox accordingly.  I think it would be
good if we could thrash this out with each other first, so that rem can be
confident that we won't ask him to change it again later.  this will increase
his chances of actually trying to straighten out this currently chaotic aspect
of pox.
--------------------
Good idea.  Keep an eye out for me at the lab (weekends are likely to be a
bad time, though, since I'll probably be with Bob working on DIRED) and
we'll thrash it out.